How committing GraalVM to OpenJDK changes the rules for Project Leyden – JVM Weekly #110

As I had hoped a week ago – JavaOne did not disappoint. Admittedly, there wasn’t much big news, but we got, for example, a very good Developer Keynote, which showed e.g., Helidon Nima or innovations in ZGC. The latter, by the way, I plan to return next week: we can once again expect exciting things in the world of Garbage Collectors. Today, however, I wanted to focus on something else – because the real bomb dropped on us during the conference was the announcement of changes in GraalVM. And – surprisingly – not thanks to any specific technological revolution.

For years, what blocked GraalVM adoption the most was its unclear licensing model. While designed as an alternative to the JVM, a universal virtual machine (one to rule them all 💍), GraalVM was always firmly tied to the JDK in the minds of Java developers. However, in practice, the relationship between the two was never clear. It was developed differently, distributed differently, but most importantly, it was based on a completely different license than OpenJDK. Both the community edition (GraalVM Community Edition) and the enterprise edition (GraalVM Enterprise Edition) remained the property of Oracle.

At a glance:

GraalVM was developed in a not very transparent way and only recently began to take care of its better visibility by publishing Roadmap to the community. As we see now, it was only the beginning. During the JavaOne mentioned above, it was announced that Oracle is finally putting GraalVM Community Edition into the hands of the named community, and it will become part of OpenJDK (Enterprise Edition will remain under the old license).

What does this mean in practice? Initially, we didn’t know much, and in fact, the entire public announcement amounted to a single tweet without much detail. Those, however, have finally appeared. The entire Native Image and GraalVM JIT for Java will be committed to OpenJDK. Meanwhile, GraalVM implementations for other languages, such as Python, Ruby, R, and JavaScript, will remain under the old license. The entire development process for the CE version of the project will also be unified with how new JDK releases are made. So in practice, this means two releases a year, LTS once every two years, and JEPs. GraalVM will thus become a viable part of OpenJDK, finally being able to enter into natural synergy with other parts of the project. After all, the history of such so far has been very, very bumpy.

After all, few remember that Java had its own AoT compiler as of JDK 9, and GraalVM’s JIT implementation had already made its way into OpenJDK 10. However, both features were removed by their negligible adoption – GraalVM, despite its unclear licensing status, remained a “more complete package,” ready for production traffic and supported out-of-the-box by the most popular frameworks. For this reason, few people opted for the lesser-supported, experimental functionality found in OpenJDK. Now that GraalVM is becoming part of the Java that everyone uses, this de facto turnout is disappearing…. which has very interesting consequences.

Those who regularly follow work on the JVM are probably familiar with Project Leyden. The problem with Leyden is that understanding what it is really about is surprisingly difficult. It is discussed in very different contexts – an alternative to GraalVM, an AoT compiler, Java JIT optimization. It is hard to grasp what its mission and purpose are – and not even the official project pitch helps much here. Thankfully, Mark Reinhold, Chief Architect of Java, has decided to clean up this discourse by publishing the text Selectively Shifting and Constraining Computation. I guess the title was chosen in a contest for “The Least Encouraging Thing in the World to Read,” but that doesn’t change the fact that it’s worth it. In it, Mark goes through various concepts on shifting compilation steps between different phases of JVM programs – he illuminates why the old saying that there are never free lunches also holds in this regard. The text also introduces the concept of Condensers, which will now be the main focus of Project Leyden. Condensers are, by definition, transformers of an application (e.g., from source code into byte code, from interpreted byte code into compiled code), which can be freely juggled in the process of building it and composed in a way that is optimal for our application. The goal is to be able to generate an application perfectly tailored to the runtime environment, whether it is an application server or a serverless/edge function.

Of course, everything I’ve written here is a considerable oversimplification for the sake of clarity of the message. There’s a reason why Selectively Shifting and Constraining Computation is quite a long publication. If it will be enough, I have an interesting discussion of the various tradeoffs that JIT and AOT computation. The talk JIT vs. AOT: How to Pick the Right Approach recently appeared on InfoQ, and has a form of a panel discussion.

Why am I writing about it? Because it reveals well why it’s so hard to describe Leyden, and at the same time, allows us to understand many of the project’s activities. When news broke this June that Project Leyden would delay work on the AoT compiler in favor of JIT optimization, it didn’t mean a complete shift (heh) of the project. Its focus was temporarily shifted to another Condenser. And this is where it’s time to return to the original topic – committing GraalVM into OpenJDK allows it to be better integrated with Project Leyden’s vision. If it ever happens, we will likely be able to treat GraalVM as one more Condenser. It will also make the whole horizon related to JVM compilation clearer.

Jumping a tad to the side (but only a tad, because we are still in the scope of Project Leyden’s interests) – only a week ago, I had the opportunity to write about Google joining the Adoptium Working Group. Now, we already have the opportunity to see the first results of this. Adoptium has announced that Google and Alibaba (the Chinese company behind AliExpress) have proposed a Project Fast Startup Incubator. Its goal is to experiment with how to start Java applications faster. Under consideration are changes to Application Class Data Sharing (which Mark Reinhold wrote about in the referenced text), as well as different ways to compile Ahead-of-Time. So, as you can see, the topic is very hot, and we every big player tries to cope with it from different directions. The reason is very clear – again, it’s cloud, Serverless, and Edge Computing. Cloud providers and big industry players are eager to make Java as convenient as possible in this context. After all, it does not fall off the list of the most popular programming languages.

And to close the whole thing with a nice buckle – a new version of GraalVM – 22.3. Among other things, it provides support for JDK 19 and its experimental features. This includes Loom, for which the developers have prepared a particular demo of a super-efficient implementation of Games of Life. The jwebserver, still available in JDK 18, has also appeared.

The download of GraalVM has also been made easier. Now all you have to do is fire up the command

bash <(curl -sL https://get.graalvm.org/jdk)

to download the current version of the project. This can be useful, for example, in a CI environment. Meanwhile, for the convenience of all of us, there are new official Reachability Metadata for projects such as Hibernate, Jetty, Thymeleaf, JAXB.

As for internals, things are interesting here as well, thanks to new support for jlink or the new version of Native Build Tools 0.9.15. Tool developers, meanwhile, have received a new Native Image API to help integrate third-party tools with GraalVM.

To conclude, I can’t help but mention that the project has received its own mascot. It is Grabbit, and I’ll admit, frankly, it is the last thing I could associate with the GraalVM, but I generally really like it when software projects have mascots…. so happy to see you, Grabbit!

I recommend reading the release post itself, in which the developers boast updates for runtime environments other than Java, but also fixes in the compiler itself.